Real-time Reactive Programming for Embedded Controllers

Software-based ontrollers for physi al devi es and pro esses must provide both algorithmi fun tionality, whi h is the usual fo us of omputer programming, and timely management of events. Combining these essential aspe ts is the hallenge of real-time programming. This paper takes a fresh look at the fundamental issues of this dis ipline and proposes a syntheti approa h that an provide ertain guarantees that temporal spe i ations will be met. 1. EMBEDDEED REAL-TIME, REACTIVE SOFTWARE Many resear hers during the past several years have explored ways in whi h fun tional programming languages, extended with monads to permit dis iplined uses of e e ts, an be applied to programming problems that have formerly been onsidered to require the use of lower level, imperative languages. In virtually every ase in whi h this paradigm has been tested, it has resulted in simpler, learer programs that bene t from the power of abstra tion, expressive type systems and on iseness of fun tional language notations. This paper takes extended fun tional programming into a new domain, that of embedded, rea tive software with expli it time onstraints. Embedded software has be ome ubiquitous in the devi es, applian es and vehi les in ommon use today. The term refers to software whose role is to de ne the behavior of a host system that in orporates physi al devi es, operates ontinuously in real time and does not require dire t human ontrol or intera tion. In an in reasing number of appli ations, an embedded software ontroller a ts as a surrogate for a human as, for instan e, in the anti-lo k braking system of an automobile. Embedded software an be a tive, when it de nes the temporal behavior of a pro ess, or rea tive, when it responds to The resear h reported here has been supported by DARPA ontra t number F33615-98-CCC-3516. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 2001 ACM 0-89791-88-6/97/05 ...$5.00. signals from external pro esses. The software ontrolling a digital musi synthesizer is primarily a tive; the software ontrolling an anti-lo k braking system is primarlily rea tive. This paper is on erned with the temporal aspe ts of rea tive embedded software. A surprising fa t about the a epted design notations for soalled real-time software is that time is rarely mentioned, or at least is not mentioned expli itly. The terminologies more ommonly used to spe ify temporal behaviors are rates of periodi pro esses and priorities of aperiodi ones. This paper explores the onsequen es of dire tly spe ifying the temporal onstraints imposed by a host system on its software ontroller, with the motivation that the ontrol required of the program might be dedu ed from su h a spe i ation. The apparently hallenging task of programming real-time responses an be made de larative! A rea tive program responds to input events from a host system by produ ing output events that are transmitted as signals to the host. Its responses are e e ted by programmed rea tions; ode sequen es that are fun tional in the sense that we understand fun tions to be interpreted in monads that a ount for e e ts. We think of rea tions as fun tions from State to State, interpreted in the Events monad. O'Haskell [9℄ is a programming language parti ularly well-suited for writing rea tive programs. The ontrol of a rea tive program determines whi h rea tions shall be invoked in response to anti ipated input events. This ontrol ould be des ribed in imperative programming style, as it is in the Esterel language [2℄, or in a fun tional style, as it is in Lustre [4℄. In this paper we shall show how the ontrol for a real-time rea tive program an be derived from a spe i ation of the temporal onstraints on its behavior. Se tion 2 dis usses general hara teristi s of embedded, rea tive software. Time onstraints are introdu ed in Se tion 3. In Se tion 4 we outline an algorithm for omputing a s hedule that assures that de lared time onstraints will be met. Se tion 5 des ribes obje ts in O'Haskell and argues why its semanti s are appropriate to real-time rea tive programs. An example is presented in Se tion 6. Se tion 7 dis usses the integration of omputationally demanding, riti al-rate tasks with timeriti al tasks. The paper on ludes with a dis ussion of related work. 2. CHARACTERISTICS OF REAL-TIME REACTIVE SYSTEMS In a typi al real-time appli ation, the task of an embedded software system is to rea t to signals generated by a host system in whi h it resides, providing output signals to e e t ontrol of the host system. The host may be a physi al system, equipped with sensors of time-varying parameters of its state, and with a tuators that operate motors, valves or other physi al ontrol devi es. A host system might also in lude ommuni ations hardware, real-time databases, or other time-varying data sour es. In su h an appli ation, the embedded software is not only required to deliver fun tionality, but to simulate a pro ess that is loosely syn hronized in time with external pro esses in its host system. Physi al pro esses in the host system are onsidered to evolve in ontinuous time. The time onstraints imposed by a host system add a hallenge to the task of programming embedded software. A spe i ation for a real-time, rea tive, software ontroller results from analyzing the host system in whi h the ontroller is to be embedded. Intera tions between the ontroller and the host system o ur through dis rete events. An input event is a dis rete, atomi message from the host system to the ontroller. Ea h o urren e of an input event is registered when it arrives at the ontroller. Registration of an input event implies that the fa t of its o urren e has been re orded in a register that is readable by the ontroller. If a data word a ompanies an input event, we shall assume it is lat hed in a designated register that an be read by the software. A software ontroller rea ts to o urren es of input events by emitting output events to its host system. The rst task in analyzing the requirements for a ontroller is to determine what input events it must respond to and what output events may be expe ted in response to ea h of these inputs. The next task is to determine timing onstraints that relate these events. Both the expe ted responses to input events and the timing onstraints may depend upon the mode of operation of the host system. For example, the operational mode of an air raft when taxiing on the ground at low speed is very different from the mode of the same air raft in ight. When taxiing, inputs from airspeed and altitude measurement sensors require no response and an be ignored, while inputs from wheel rotation sensors are signi ant. An input from the pilot's ontrol yoke may be interpreted di erently (i.e. may evoke di erent responses from the ontroller) when an air raft is taxiing than when it is airborne. Furthermore, the time onstraints imposed to a hieve stable ontrol might be expe ted to be more lax when an air raft is taxiing than when it is in ight. 2.1 Hybrid systems A hybrid system design ombines the aspe ts of a ontinuous state spa e with a nite set of operating modes that partition the state spa e. The hybrid system on ept is widely used to organize and simplify the design of ontrols for highly nonlinear systems. In a hybrid design, the ontrol laws used to regulate or guide a system may be swit hed as the system's state traje tory transitions between modes of operation. From the vantage point of the ontrol engineer, the operating modes of a dynami al system are regions of its state spa e in whi h the system dynami s may be approximated by a simpli ed system. The simpli ed dynami s is only expe ted to provide an a urate approximation within a dened region of the system's state spa e. When operating in di erent modes, the system state is subje t to di erent sets of onstraints, and onsequently, may satisfy a di erent set of dynami al equations. The state and ontrol signals in a hybrid system may have both ontinuous and dis rete aspe ts. A quantity that varies ontinuously with time may be modeled by a time series of dis rete values. A dis rete event an be lo alized in time. A dis rete event may be said to o ur in a time interval during whi h the ( ontinuous) traje tory of a state variable rosses a designated threshold, as, for instan e, when the wheels of an air raft tou h the ground in landing. Control signals may also have dis rete aspe ts, as when a motor is turned on, or a braking a tuator is applied. From the vantage point of a software engineer who is ontemplating the design of an embedded software ontroller, its operating modes orrespond to dis rete states of a nitestate transition system. A ontrol state is hara terized by two maps: 1. A mapping from anti ipated input events to programmed rea tions. A rea tion may emit output events and update the internal state variables of the ontroller. 2. A mapping of input events to ontrol-state transitions, whi h may be guarded by boolean predi ates over the internal variables. In this view of a ontroller as a hybrid system, the ontroller weakly simulates the ontrolled system, tra king its mode transitions with transitions of the ontroller's own ontrol states, and tra king the traje tory of the system's state within modes through dis rete hanges in the ontroller's internal state variables. 2.2 Control states and guarded reactions Rea tive programs are often designed as nite transition systems. Although the systems we onsider may mutable state variables, this notion of state is not the one we wish to onsider as dis rete, be ause the spa e of valuations of the state variables may be in nitary or even ontinuous. Rather, we wish to onsider a nite partition of this spa e, whi h we shall refer to as the set of ontrol states of the system. A ontrol state is hara terized by a mapping of input events to nite sets of guarded rea tions. A guarded rea tion is prefa ed by a boolean predi ate over the state variable. The meaning of a guarded rea tion is that if its guard evaluates True, the rea tion is enabled, otherwise it is not. A ontrol state is deterministi if at most one guard on its set of guarded rea tions an be True for any valuation of the state variables, otherwise it is nondeterministi . When a set of guarded rea tion is dispat hed in response to an input event, its guards are evaluated, and if any rea tion be omes enabled, one of the enabled rea tions is sele ted for invo ation. Sin e a rea tive program is of bounded length, it an ontain only a nite number of guarded rea tions, hen e, there is only a nite number of ontrol states, no matter what may be the ardinality of valuations state variables. Sin e exe uting a rea tion may alter the values of state variables, it an indu e a transition of the ontrol state, i.e. hange the values of some guards. Guards must be restri ted so as not to ontain alls to re ursively de ned fun tions, so the evaluation time of a guard an be bounded. Guards are pure expressions, i.e. they an be interpreted in the Identity monad. 2.2.1 Hierarchical transition systems and concurrent objects A rea tive system is often designed as a olle tion of intera ting omponent subsystems, whi h operate on urrently and intera t asyn hronously by ex hanging messages. A system designed in this way an be modeled as a system of nested, nondeterministi , nite automata [5℄. It an be implemented as a system of on urrent obje ts with asynhronous methods to support intera tion. In a on urrent obje t implementation, a rea tive system has a omposite state represented by the internal, private state variables of its omponent obje ts. The omposite state of the system is distributed over the states of its omponents. Rea tions are realized by method invo ations. Distin t obje ts may exe ute methods on urrently, orresponding to on urrent transitions of independent transition systems. As obje ts have private state variables, methods of distin t obje ts share no ommon variables and hen e do not interfere when exe uted on urrently. 2.3 Synchronizing a controller with external processes The \real-time" aspe t of an embedded software ontroller is the requirement that it must be syn hronized with one or more external pro esses in its host system. The pre ision needed in this syn hronization is alibrated by the time delay that an be tolerated between the arrival of an input event and the delivery of an output event in response to the input. If syn hronization is not suÆ iently pre ise, the a ura y of information represented by a series of input events will be degraded, as well as the a ura y of the ontrol effe ted by a series of output events. Extreme degradation of ontrol a ura y be ause of ex essively delayed response an result in loss of stability of the dynami al system under ontrol. The pre ision required to syn hronize a ontroller with its host system depends upon the nature of the intera tion and may not be uniform over all lasses of events, even within a single appli ation. We shall all the allowable time delay between an input and an output the response time of the input-output pair. The required response times for events in a system an be represented by a partial fun tion response time : Inputs Outputs ! Time. When there are multiple hannels for intera tion between a ontroller and its host system or when the host system is omprised of several independent pro esses, multiple input events may arrive simultaneously at the ontroller. In physi al terms, simultaneity means that the separation in arrival times of two or more events is less than the temporal pre ision with whi h event arrivals are registered. When input events annot be separated by their time of arrival, it makes no sense to s hedule their responses in order of arrival. Instead, the spe i ed response times for inputoutput pairs provides a s heduling riterion. A riterion for a su essful s hedule of responses is that regardless of the order in whi h input events may have arrived, the response to every input event is emitted within the required response time. 2.4 Process velocity and inter-event latencies Another fa tor in uen ing the design of a software ontroller is the rate or rates at whi h external pro esses in the host system are able to deliver input events to the ontroller. The anti ipated event arrival rates, multiplied by the per event ost of pro essing, determine the pro ess performan e required of a ontroller. Event arrival rates are not ne essarily uniform, as some lasses of events may o ur at unpredi table times. Nevertheless, there is inevitably a latent period separating the generation of an event by a pro ess from the generation of a subsequent event by the same physi al pro ess. Informally, we refer to the rate at whi h a pro ess is apable of generating event o urren es as its pro ess velo ity. A re ipro al measure is the minimum inter-event laten y of the pro ess. Sin e we do not ordinarily wish to spe ify in detail the external pro esses that onstitute the host system of a software ontroller, we shall instead spe ify inter-event laten ies dire tly. The laten ies hara terizing the maximum velo ities of external pro esses an be spe i ed by de ning a partial fun tion, laten y :: (Inputs [Outputs) Inputs ! Time. 2.4.1 Clocks Periodi sampling of a ontinuous pro ess provides a uniform pro ess velo ity as observed by intera tions with a ontrol pro ess. The apparent velo ity of a sampled pro ess is determined by the frequen y of a lo k pro ess that strobes sensors of its observable parameters. A lo k is ne essarily a pro ess external to a software ontroller, be ause the software has no inherent a ess to the timing provided by the hardware pro essor that exe utes it. We distinguish three ommonly used modes of intera tion with an external lo k pro ess: a syn hronizing lo k delivers a stream of primitive input events (ti ks) to whi h a software ontroller rea ts. A ti k event arries no data, but ti ks may be a umulated in an internal state variable as a measure of elapsed time. The ti k of a syn hronizing lo k provides an event at whi h a software ontroller an be a tivated to rea t to any input events that have arrived sin e the pre eding lo k ti k. a metri lo k does not deliver input events, but provides a read-only register that an be read at any time to provide a measure of \absolute" time. This allows the ontroller to measure elapsed time by taking the di eren e between a urrent and a prior reading of the metri lo k register. an interval timer is a lo k that an be set by an output event emitted by the ontroller. A timer-setting event spe i es a time interval after whi h the lo k will respond with an input event. A real-time operating system normally provides a timing servi e that in orporates one or more of these modes of lo k intera tion. 2.5 Reactions take time In de ning the syn hrony assumption in onne tion with rea tive programming, Berry and Gonthier state that \rea tions are presumed to be instantaneous" [2℄. This slogan represents the assumption that the omputation time needed for a ontroller to al ulate a rea tion to a given input event is very mu h less that the allowed response time to this or any other event. Insofar as this assumption is valid, the output events emitted by a rea tion to an input event o ur syn hronously with the input event. Re ning this notion slightly, the idea of syn hrony an be tied to the pre ision with whi h the time of o urren e of events an be dis riminated, by any observer in a system. If an observer an dis riminate events a and b whenever they are separated by an interval of at least t, then the response time for a rea tion that responds to a by emitting b must be less than t, for otherwise, the system's temporal spe i ation would be suÆ iently lax that an observer might dete t the delay introdu ed by its pro essing of events. Clearly, the assumption of negligible rea tion times is not valid in all ir umstan es. In developing a dis ipline of realtime rea tive programming, we are interested in situations in whi h rea tion times must be a ounted for. We shall relax the assumption of instantaneous rea tions to one that seems more realisti . We assume that for ea h rea tion, there is a stable distribution of its exe ution times, whi h an be estimated by measurements ondu ted on the omputing platform on whi h an embedded software system is to be installed. We assume that these distributions have Gaussian tails and therefore allow us to predi t upper bounds on the exe ution times of individual rea tions that an be expe ted to hold with probability as near to 1 as is required. Let Rea tionTime :: Rea tions ! Time, where Time is a type synonym for the positive real numbers. Rea tionTime is an upper bound on the time taken for a syn hronous exe ution of the rea tion . Unlike response time and laten y, rea tion times annot be obtained by analysis of requirements imposed by the host system. Rea tion times an be determined only after a software ontroller has been designed and implemented. One way to determine rea tion times is by measuring the time taken for repeated exe utions of rea tion odes on a platform nearly identi al to that on whi h the ontroller is to be installed. From the measurements, one an determine a distribution of times for ea h rea tion. The distributions provide an empiri al basis from whi h to estimate upper bounds on the exe ution times of individual rea tions. 2.5.1 Reactions are atomic actions Rea tions are fun tions (interpreted in the Event monad1) that are programmed to implement the fun tional requirements of an embedded ontroller. A rea tion is applied to the urrent state of the ontroller in response to an input event. The omputation of a rea tion must o ur atomially and without noti eable interruption of pro essor servi e, for otherwise, rea tion times ould not be predi ted with any degree of on den e. Furthermore, the ode body of a rea tion must not ontain alls to any re ursively dened fun tion, nor an it invoke other rea tions, be ause its exe ution time must be uniformly bounded. Viewed as pro edural ode, the body of a rea tion an have no loops. However, the s heduling of rea tions need not be programmed as it would be in an imperative rea tive language. Time-bounded rea tions an be dispat hed in response to arrivals of input events a ording to xed s hedule. If there exists any feasible s hedule that an assure that exe ution of time-bounded rea tions an always satisfy the time on1The Event monad is a omposition of a state monad with a monad whose e e ts are dis rete intera tions with a host system. The ommand emit [event℄ is a non-proper morphism of the Event monad. The state obje t of the monad is internal to the program and is not visible to the host system. straints of a temporal system spe i ation, then su h a s hedule an be al ulated stati ally from the system spe i ation and the bounds established on rea tion times. In Se tion 4 we present an algorithm for al ulating a feasible stati s hedule. 3. TIME-CONSTRAINED EVENT SYSTEMS Taking a more abstra t view of real-time systems, we shall designate as an event any intera tion between a program and the environment in whi h it runs. An event may arry a value or not. An event lass is designated by an identi er, optionally bound to a type. Let Events be a nite set of events, Inputs Events be a nite set of input events, Outputs Events be a nite set of ouput events, This partition of events is arbitrary, but useful in on eptualizing the intera tions of a program with its environment. 3.1 Specifying temporal properties The host system of an embedded ontroller determines temporal onstraints on the intera tions of the ontroller with the host system. A temporal system spe i ation binds identi ers to the possible input and output events, gives the type of data (if any) that a ompanies an event, and pres ribes onstraints on the temporal orderings of events. Inputs :: identi er j : : : j identi er Outputs :: identi er j : : : j identi er ResponseTime :: (Inputs;Outputs)! Time DelayedResponse :: (Inputs [Outputs;Outputs)! Time Laten y :: (Inputs [Outputs; Inputs)! Time The onstraints that de ne temporally orre t behavior of the ontrol pro ess are interpreted as follows. If ResponseTime(a; b) is de ned and yields the time interval Æa;b, then whenever an o urren e of event a evokes emission of event b in response, event b must be emitted no later than Æa;b se onds after event a has arrived. Response times hara terize a rea tive pro ess. If DelayedResponse(a; b) is de ned and yields the time interval a;b, then whenever an o urren e of event a evokes emission of event b in response, event b may o ur no earlier than Æa;b se onds after the o urren e of event a. Delayed responses hara terize an a tive pro ess. If Laten y(a; b) is de ned and yields the time interval a;b, then we an be assured that an o urren e of input event b will never happen earlier than a;b se onds following an o urren e of event a. An un onstrained input event may potentially o ur at any time. Therefore, we expe t that a omplete temporal system spe i ation will in lude a laten y relation for every possible input event. In parti ular, it is quite ommon to have a laten y spe i ation of the form Laten y(a; a) = Æa, whi h pres ribes the minimum time in whi h an input event a an follow a previous o urren e of the same sort of event. A temporal system spe i ation must be a ompanied by a fun tional des ription of a host system, whi h may be given formally or informally. A fun tional des ription spe i es the modes of operation of the host system and determines what outputs should be emitted in reponse to possible inputs in ea h of the operating modes. 3.1.1 Satisfying response time constraints The dis rete event hypothesis arose be ause of limited ability to resolve o urren es of events in ontinuous time. Events whose arrival times annot be resolved are onsidered to have o urred simultaneously. As a simplifying assumption, suppose that the rea tion to a set of two or more input events an be any sequential omposition of the rea tions to the individual events, as if they had arrived in an arbitrary order. A suÆ ient ondition for a system of syn hronous rea tions to satisfy the response time onstraints of a system is met if a. the laten y relation forbids the o urren e of an unbounded number of events in any nite time interval, and b. for any set of events whose laten y onstraints do not pre lude their simultaneous o urren e, the sum of rea tion times is less than the spe i ed response time for any rea tion to an event in the set. However, the above ondition may be far more stringent than ne essary, for it fails to take into a ount our ability to s hedule the dispat h of rea tions to a set of input events that await responses. 4. INFERRING A FEASIBLE SCHEDULE FROM REAL-TIME CONSTRAINTS Given a nite set of enabled rea tions, ea h with a predi table exe ution time and a deadline time by whi h ea h rea tion is to be ompleted, an earliest-deadline rst (EDF) algorithm [8℄ will determine a feasible s hedule, if one exists. This easy s heduling problem is ompli ated by the arrivals of new input events that enable additional rea tions. We must frame the algorithm in relative time, rather than absolute deadline times, be ause the response times allowed for rea tions are measured from the time of arrival of events. We must also take into a ount the laten ies that onstrain the arrival of input events, for otherwise, a system may be overloaded with an unbounded number of input events that require timely responses. New events may arrive from the host system while the ontroller is dormant or while it is exe uting a rea tion to a previously registered event. We assume that the ontroller is a tivated immediately if a new event should arrive while it is dormant. (This might be a omplished by preempting the exe ution of a non-real-time task.) When a rea tion ompletes exe uting, the ontroller polls registers in its environment to determine if new events have arrived. If events have arrived, the ontroller's dispat h fun tion determines whi h rea tion should be the next to exe ute. We shall onsider the problem of al ulating a stati s hedule, or dispat h table, for ea h ontrol state of the ontroller. A s hedule is al ulated from the temporal spe i ation of events required by the host system and the exe ution time bounds for rea tions. Sin e the laten ies onstraining the arrivals of input events depend upon the history of a tivity (both input events reently arrived and output events re ently emitted), dis overing a feasible s hedule has aspe ts of a dynami programming problem. We al ulate a s hedule over a bipartite tree, whose nodes are labeled by on gurations of timeonstrained event sets. A s heduling on guration is represented as a re ord of type: fstate :: State; evts :: f(Inputs Int)g; onstrained :: f(Inputs Int)gg where state represents the simulated ontrol state, evts is a set of input events whose arrival has been registered with the ontroller, ea h paired with a bound on the (simulated) time sin e its arrival, and onstrained is a set of laten yonstrained events, ea h paired with a lower bound on the time remaining until an event of this sort might arrive. Transitions of the ontrol state are determined by a state transition fun tion, transition : State Rea tion ! State. A on guration, C, is said to be feasible if it satis es the following ondition. For ea h pair (e; t) in evts, let the asso iated rea tion, when the ontroller state is s, be denoted by s;e (noti e that this rea tion might be null). Let !s;e designate the set of output events that might be emitted by s;e. Let s;e = mine02!s;eRT(e; e0). The feasibility ondition for a on guration is: feasible(C) = 8s : State 8(e; t) 2 C:evts ( s;e t Rea tionTime s;e 0) _ ( s;e = null) The al ulation of a s hedule elaborates a bran hing-time, temporal simulation of the possible intera tions of the ontroller and its host system. This simulation an be modeled as a nitely bran hing tree of unbounded depth. A s heduling tree ontains two types of nodes, whi h alternate along any path des ending from the root. The node types are: dispat h nodes. Ar s emanating from a dispat h node are labeled by rea tions. arrival nodes. Ar s emanating from an arrival node are labeled by sets of input events. A s heduling tree is like a game tree. At a dispat h node, any outward ar may be hosen to ontinue elaboration. At an arrival node, no hoi e is allowed. The simulation must be elaborated along all outward ar s. The root of a s heduling tree is labeled by an arrival on guration that spe i es the initial ontrol state, an empty set of registered events, and an empty set of onstraints on arriving events. To elaborate an ar from an arrival node labeled by C and whose in ident ar is labeled by rea tion , onstru t outgoing ar s labeled by members of the powerset, }(Inputs f 0 j ( 0; t) 2 C. onstrainedg). The on guration labeling the node rea hed by an ar whose label is is: fstate = C.state; evts = C.evts [ f(e; t) j e 2 ^ t = Rea tionTime g; onstrained = C. onstrainedg A newly arrived event is pessimisti ally assumed to have arrived at the time the pre eding rea tion was invoked, thus when exe ution of the rea tion on ludes, the event has already been resident for the duration of the rea tion time. To elaborate an ar from a dispat h node labeled by feasible on guration C, hoose (e; t) 2 C.evts, if C.evts is not empty. Let e = rea tionTo(C.state; e). Form a new node labeled by the on guration, C0 = fstate = transition(C.state; e); evts = f(e0; t0) j (e0; t) 2 C.evts ^ e0 6= e ^ t0 = t+ Rea tionTime eg; onstrained = f( ; t0) j ( ; t) 2 C. onstrained ^ t0 = t Rea tionTime e ^ t0 0gg Label an ar from node C to C0 with the rea tion e. If a node label is not a feasible on guration, then that node has no su essors in the tree. A s heduling tree is feasible if at every dispat h node, C, either C.evts 6= [ ℄, or C has at least one feasible su essor. 4.1 Configuration subsumption The purpose of elaborating paths in a s heduling tree is to dis over and eliminate paths that inevitably lead to infeasible on gurations. These, along with the paths that terminate on dispat h nodes with empty evts sets, are the nite paths in the tree. Clearly, we must have a riterion for stopping the elaboration of a path when we dis over that it is not nite. Algorithm termination is based upon the notion of on guration subsumption. Informally, we say that a on guration C subsumes a on guration C0 if for every feasible path elaborated from C0, there is a orresponding path that an be elaborated from C. The notion of orresponden e of two paths is that they have the same sequen e of edge labels. More pre isely, we say that C subsumes C0 if the following onditions are satis ed: C:state = C 0:state 8(e0; t0) 2 C 0:evts 9(e; t) 2 C:evts e = e0 ^ t t0 8( ; t) 2 C: onstrained 9( 0; t0) 2 C 0: onstrained e = e0 ^ t t0 That is, C0 has the same state as does C, every event registered in C0 is also registered in C with possibly longer time of residen e in C than in C0, and every event onstrained in C is also onstrained in C0 with its time of onstraint in C possibly shorter than in C0. 4.2 A static scheduling algorithm We have implemented a s heduling algorithm in Haskell whi h elaborates a s heduling tree as outlined above. Its result is either a s hedule, represented by a set of quadruples of type (State }(Inputs) Inputs Rea tions), or it reports failure. A quadruple (s; evts; e; r) is interpreted by the dispat h fun tion of a ontroller to mean \when in state s with a set of registered input events evts, dispat h rea tion r and retire event e". The algorithm returns only a single feasible s hedule, although there may be many. If the hoi e of a rea tion to hoose in elaborating a dispat h node of the s heduling tree does not result in a feasible s hedule, other hoi es must be explored for ompleteness. The algorithm limits its hoi es to the EDF strategy. Although this strategy is not omplete for the s heduling problem we have posed, it seems that it would require a pathologi al onstru tion to demonstrate an example on whi h EDF fails, yet a feasible s hedule exists. Con guration subsumption limits the depth of exploration of a s heduling tree. The algorithm maintains two lists of on gurations whose feasibility has been resolved: those from whi h a feasible, in nite path from a dispat h node labeled with the on guration in known to exist and those for whi h it is known that there is no su h feasible path. In addition, it maintains a list of the unresolved on gurations of dispat h nodes on the path from the node being explored ba k to the root. Whenever the urrent node's on guration subsumes a previously su essful on guration or the unresolved on guration of an an estor node, the algorithm eases to elaborate its su essors. Either the on guration has been proven to be su essful, leading to at least the same feasible paths as the su essful on guration that it subsumes, or the algorithm has dis overed a path segment that an be repeated inde nitely, implying that no new information will result from its further exploration. Whenever the on guration of the urrent node is subsumed by that of a node that generates only infeasible paths, it has been proven to be unsu essful, for either it mandates more stringent deadline onstraints or it allows un onstrained events to enter sooner than does the on guration that subsumes it. The lazy evaluation of Haskell limits the amount of omputation ne essary to nd a feasible s hedule. The algorithm simulates ba ktra king by produ ing a list of the feasible s hedules that an be dis overed from ea h hoi e point [11℄. These lists are, of ourse, evaluated lazily, and often only the rst element is demanded. The strategy of saving both the feasible and infeasible on gurations that have been en ountered in elaborating a s heduling tree e e tively gives the algorithm a dynami programming behavior rather than that of a less eÆ ient, ba ktra king algorithm. 5. ASYNCHRONOUS REACTIVE OBJECTS IN O’HASKELL Components of a rea tive system designed as a hierar hy of intera ting, nite-state transition systems are quite naturally programmed as obje ts with a parti ular set of hara teristi s. Ea h omponent automaton an be represented by an obje t. Obje ts used in this way have a number of hara teristi s: Independen e|distin t omponents do not share state; Con urren y|a tions of distin t obje ts may exe ute on urrently with respe t to one another; Asyn hrony|interomponent ommuni ation normally o urs through non-blo king messages; Sequentiality|the a tions of an individual omponent o ur in sequen e, not interleaved; Passivity|a omponent is a tivated only by the messages to whi h it rea ts; it has no ba kground a tivity; Sin e obje ts do not share state, omponents are oupled only through their message-passing interfa es. This allows their a tions to be exe uted on urrently without additional syn hronization. An asyn hronous message triggers the exeution of a method in an obje t, but the sender of a message does not await a return. The sender of a message and the a tor whi h re eives the message and rea ts to it are not syn hronized. Sin e the a tions (method exe utions) of an obje t do not blo k on messages they may send, ea h a tion, on e initiated, an be exe uted to ompletion. An obje t exe utes its a tions sequentially, without interruption. Furthermore, an obje t is a tive only when it is exe uting one of its methods in response to a message it has re eived. This set of hara teristi s (one might all them restri tions on an obje t's behavior) is hara teristi of the a tor model of omputation [1℄. It has been used as a basis for the semanti s of obje ts in O'Haskell [9℄, a fun tional, obje toriented programming language. 5.1 O’Haskell—a functional language with simple objects O'Haskell embeds a purely fun tional expression language based upon Haskell version 1.3, omplementing the expression language with obje ts that en apsulate state. Unlike onventional OO languages, O'Haskell does not support obje t inheritan e, in whi h a hierar hy of obje ts an share omponents of state with other obje ts above them in the hierar hy. It does support subtyping, allowing a programmer to de lare a hierar hy of obje t types. The methods of O'Haskell obje ts are rstlass entities, as are the obje ts themselves. The monadi type system inherited from Haskell eliminates the possibility of onfusion between statements and expressions. We have used O'Haskell for prototyping rea tive systems programs. 5.1.1 O’Haskell has no explicit threads One of the most taxing aspe ts of on urrent programming in a onventional OO language, su h as Java, is synhronizing the a tivities of multiple threads. In Java, threads are expli itly reated by a program. Multiple threads an be a tive in an obje t and thus an potentially share simultaneous a ess to the obje t's state. To ensure deterministi behavior for an obje t in whi h multiple threads an run, thread a tivities must be syn hronized with monitors that ontrol a ess riti al regions of ode in whi h state variables may be a essed. In O'Haskell, threads are impli it, rather than expli it. Exa tly one thread is allo ated (impli itly) for ea h obje t. That thread is awakened when the obje t exe utes a method in response to a re eived message. The thread is dormant when there are no outstanding messages for the obje t. 5.1.2 Synchronous and asynchronous methods A method of an O'Haskell obje t may be either a synhronous or an asyn hronous a tion. A syn hronous request returns a value to the sender of a message alling the request. The sender waits for the result. An asyn hronous a tion is non-blo king on the sender of a message. The omputational onsequen es of an asyn hronous a tion an be seen in the update of an obje t's state, or in the re eipt (by other obje ts) of additional messages that may be sent in exe uting the a tion. Requests and a tions are typed in the Obje t monad in the O'Haskell type system, so that they annot be onfused with pure fun tions. (The Obje t monad may be onsidered to subsume the IO monad of Haskell.) An method typed in the Obje t monad an referen e the state variables of the obje t and an be omposed of ommands that in lude destru tive assignments to obje t variables, as well as sending messages to obje ts. O'Haskell provides a onvenient do syntax that an be used in the ode body of a method to ompose sequential ommands. 6. EXAMPLE: THE REFLEX GAME As an illustration, we shall onsider the Re ex Game, a simple rea tive system that has been widely studied as an example problem for rea tive programming languages [3, 7℄. Here, however, we shall expli itly spe ify temporal onstraints on the game. In the Re ex Game, a human player tests the speed of her re exes by pressing a button as qui kly as possible after given a signal to do so. The ontroller measures the elapsed time between display of the go-ahead signal to the player, and sensing the button push. To deter anti ipatory responses by the player, the ontroller delays display of the go-ahead signal by a randomly sele ted interval following the player's signal that she is ready to play. An early push of the button by the player terminates the game. If the player pushes the Ready button when it is not expe ted, a warning bell is sounded. A new game is initiated by the player by depositing a oin in a slot. A game onsists of a xed number of trials. Following this informal des ription of the game, we spe ify the input and output events of the ontroller: Input Events Coin, Ready, Stop Output Events Game_light_on, Game_light_off, Warning_bell, Go_ahead_light_on Go_ahead_light_off, Tilt_light_on, Tilt_light_off, Display (Int) The response time onstraints impose maximum times (in millise onds) between an input event and an output event delivered in response to that input. Laten ies provide minimum intervals that separate an input event from a spe i ed sort of pre eding input (or output) event. Response Times (Coin,Game_light_on,250), (Ready,Warning,150), (Stop,Go_ahead_light_off,10), (Stop,Warning_bell,150), (Stop,Game_light_off,150), (Stop,Tilt_light_on,150) Laten ies (Coin,Coin,2000), (Ready,Ready, 1000), (Stop,Stop,1000) Noti e that in the set of temporal onstraints de lared above, the output event Go ahead light o delivered in response to a press of the Stop button has a mu h shorter response time than any of the other events. We shall return to this issue when we dis uss the al ulation of a s hedule. One more spe i ation is needed to govern the temporal behavior of the system. Delay times spe ify minimum intervals that separate output events when there are no intervening arrivals of input events. Delay times regulate the rates at whi h spontaneous generation of outputs an o ur. In the spe i ations given below, two sorts of spontaneous output events are regulated. The Game light off event, o urring spontaneously, ends a game be ause there has been no input from the player for a predetermined timeout interval. The Display event may o ur spontaneously to refresh the display at the beginning of a new trial. The delay spe i ed between o urren es of the Display event ensures that if the user does not initiate a new trial herself, the display will hold the value of her re ex time for a spe i ed interval. Delays (Go_ahead_light_on,Game_light_off,10000), (Game_light_on,Game_light_off,10000), (Warning_bell,Game_light_off,10000), (Display,Display,3000), (Display,Game_light_off,3000) 6.1 The Reflex Game as a hybrid system Although the ontroller for the Re ex Game is not required to simulate the dynami al behavior of a ontinuous system, it must nevertheless maintain an approximate re ord of the passage of time, in addition to other, dis rete state variables. From the point of view of the designer, a hybrid system is one in whi h there is a nite spa e of ontrol states that is mu h smaller than the state spa e of valuations of the ontroller's state variables. For the Re ex Game, we have designed a ve-state ontroller. States Idle, Holding, Counting, Play and Display orrespond to the operating modes informally des ribed above. A state transition diagram is shown in Figure 1. From the diagram in Figure 1, the reader will noti e that the system makes transitions guarded by temporal events| when the elapsed time in a state ex eeds a given bound| in addition to transitions triggered by input events. The bounds on elapsed time spent in states Play, Counting and Display are extra ted from the delay de larations given in the pre eding se tion. For instan e, a transition from state Play to Idle an o ur 10000 mse . after a transition into the Play state, if no input-indu ed transition has o urred. This is determined from the delay onstraint between an o urren e of output event Game light on, whi h is emitted by the rea tion to a Coin drop event, and an o urren e of Game light off, whi h is emitted by a rea tion that a ompanies entry into the Idle state. The bound on elapsed time in state Holding is a value al ulated from a pseudo-random sequen e generator. 6.2 Scheduling reactions of the Reflex Game Spe i ations of input and output events, response time onstraints, delay times and laten ies are obtained from the problem spe i ation, The set of ontrol states, state transitions, the set of rea tions and the output events emitted by ea h rea tion annot be gotten by spe i ation alone but may be extra ted from the program of a ontroller by a straightforward analysis. The exe ution times of rea tions annot be determined a urately by analysis, but a distribution an be measured. The ombined data are gathered in a text le for input to the s heduling algorithm. For the ve-state ontroller of the Re ex Game, with ten rea tions and estimated rea tion times ranging from 10 to 35 ms., the s heduler produ es a s heduling table with 76 entries. A typi al entry reads as: (Counting,[Coin,Stop℄,Stop,DisplayTime) Its interpretation is that when the ontroller is in state Counting and the set of registered events is fCoin,Stopg, then the DisplayTime rea tion is to be dispat hed, retiring the event Stop. The existen e of a feasible s hedule is sensitive to the time onstraints and the estimated rea tion times given to the s heduler. When the s heduler reports that there is no feasible s hedule, a designer has several options. Obviously, it an be important to sharpen estimates of the bounds on rea tion times. However, redesign of the nite-state transition system that de nes the ontroller an also improve s hedulability. For instan e, when the ontroller is in state Counting (refer to Figure 1) the Stop event auses a rea tion that emits a display output, whi h has a riti al response time relative to the arrival of the Stop input. However, if a Ready event were re eived just before a Stop event o urred, the Ready event would be rea ted to rst, and would leave the ontroller still in the Counting state. In the worst ase, a ounted for by the s heduler, the exe ution time for a rea tion to this hypotheti al Ready event must be subtra ted from the response time to obtain the time remaining for the rea tion to the Stop event to be ompleted. It is this sort of ir umstan e that is dete ted by the stati s heduling algorithm when it reports no feasible s hedule. A designer an sometimes remedy su h a ir umstan e by state-splitting in the design of the ontroller. In the ase outlined in the pre eding paragraph, a new state, Reset, might be introdu ed. If a Ready event o urred when the ontroller was in the Counting state, it would transition to the Reset state, from whi h the Counting state would be reentered after another random time interval. Any intervening Stop event that o urred while in the Reset state ould be ignored. The possibility of temporal ompetition between rea tions to the Stop and Ready events in the Counting state would be eliminated. Obviously, any su h redesign must satisfy the requirements of the appli ation. 6.3 A statically scheduled simulation of the Reflex Game in O’Haskell To program a simulation of the Re ex Game in O'Haskell, we have de lared a module alled game to represent the ontroller. This module takes as parameters the imported environment that provides a ess to a tuators linked to physi al ontrol of the game devi es, a stati ally al ulated s hedule for dispat hing rea tions to events (Se tion 4) and the seed of a random sequen e generator. For simulation, the module imports a Tk environment instead of an a tual ma hine to realize the game interfa e. The rst entity de lared in the body of the game module is an obje t template that de lares a set of state variables, whose s ope is restri ted to methods of the game obje t. game env s hedule seed = template -the game state and initial values state := Idle evts := Empty time := 0 :: Int rand := 0 :: Int startTime := undefined totalTime := 0 :: Int trialNumber:= 0 :: Int